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The identity of an operating system running on a computer 
is determined from an identity associated with an initial 
component for the operating system, combined with iden- 
tities of additional components that are loaded afterwards. 
Loading of a digital rights management operating system on 
a subscriber computer is guaranteed by validating digital 
signatures on each component to be loaded and by deter- 
mining a trust level for each component. A trusted identity 
is assumed by the digital rights management operating 
system when only components with valid signatures and a 
p re-determined trust level are loaded. Otherwise, the oper- 
ating system is associated with an untrusted identity. Both 
the trusted and untrusted identities are derived from the 
components that were loaded. Additionally, a record of the 
loading of each component is placed into a boot log that is 
protected from tampering through a chain of public-private 
key pairs. 
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LOADING AND IDENTIFYING A DIGITAL without permission. A publisher could also adjust pricing 

RIGHTS MANAGEMENT OPERATING according to whether the client is allowed to make a per- 

S YSTEM sistent copy, or is just allowed to view the content online as 

it is delivered. These scenarios reveal a peculiar arrange - 

RELXTED APPLICATIONS s ment. The user that possesses the digital bits often does not 

have full rights to their use; instead, the provider retains at 

This application is a continuation-in-part of U.S. provi- i eas t some of the rights. In a very real sense, the legitimate 

sional patent application Ser. No. 60/105,891 filed on Oct. user of a computer can be an adversary of the data or content 

26, 1998, which is herein incorporated by reference, and is provider. 

related to co-pending and co-filed applications titled "Sys- "Digital rights management" is therefore fast becoming a 

tern and Method for Authenticating an Operating System to central requirement if online commerce is to continue its 

a Central Processing Unit, Providing the CPU/OS with rapid growth. Content providers and the computer industry 

Secure Storage, and Authenticating the CPU/OS to a Third must quickly provide technologies and protocols for ensur- 

Party" (Ser. No. 09/266,207, filed Mar. 10, 1999, "Key- ing that digital content is properly handled in accordance 

based Secure Storage" (Ser. No. 09/227,568, filed Jan. 8, 15 with the rights granted by the publisher. If measures are not 

1999, Digital Rights Management Using One Or More taken, traditional content providers may be put out of 

Access Predicates, Rights 1999, and "Digital Rights Man- business by widespread theft, or, more likely, will refuse 

ager Certificates, And Licenses" (Ser. No. 09/227,559, filed altogether to deliver content online. 

Jan. 8, 1999). Traditional security systems ill serve this problem. There 

2Q are highly secure schemes for encrypting data on networks, 

FIELD OF THE INVENTION authenticating users, revoking certificates, and storing data 

This invention relates generally to computer operating secureI y- Unfortunately, none of these systems address the 

systems, and more particularly to booting and identifying an assurance of content security after it has been delivered to a 



operating system that enforces digital rights. 



25 



client's machine. Traditional uses of smart cards offer little 
help. Smart cards merely provide authentication, storage, 

COPYRIGHT NOTICE/PERMISSION ~ ar *d encryption capabilities. Ultimately, useful content must 

be assembled within the host machine for display, and again, 

A portion of the disclosure of this patent document at this point the bits are subject to theft. Cryptographic 

contains material which is subject to copyright protection. coprocessors provide higher-performance cryptographic 

The copyright owner has no objection to the facsimile operations, and are usually programmable but again, 

reproduction by anyone of the patent document or the patent fundamentally, any operating system or sufficiently privi- 

disclosure as it appears in the Patent and Trademark Office i eged application, trusted or not, can use the services of the 

patent file or records, but otherwise reserves all copyright cryptographic processor. 

rights whatsoever. The following notice applies to the soft- appear t0 be three sohltions t0 this pro blem. One 

ware and data as described below and in the drawings solution is to do away with g eDeral .p Urpose computing 

hereto: Copyright © 1998, Microsoft Corporation, All devices and ^ sp ecial-purpose tamper-resistant boxes for 

Rights Reserved. delivery, storage, and display of secure content. This is the 

BACKGROUND OF THE INVENTION »PP roach * d °P l f ^ ,he "ble industry and their set-top 

boxes, and looks set to be the model tor DVD -video 

More and more content is being delivered in digital form, 40 presentation. The second solution is to use secret, propri- 

and more and more digital content is being delivered online etary data formats and applications software, or to use 

over private and public networks, such as Intranets, the tamper-resistant software containers, in the hope that the 

Internet and cable TV networks. For a client, digital form resulting complexity will substantially impede piracy. The 

allows more sophisticated content, while online delivery third solution is to modify the general-purpose computer to 

improves timeliness and convenience. For a publisher, digi- 45 support a general model of client -side content security and 

tal content also reduces delivery costs. Unfortunately, these digital rights management. 

worthwhile attributes are often outweighed in the minds of This invention is directed to a system and methodology 
publishers by the corresponding disadvantage that online that falls generally into the third category of solutions, 
information delivery makes it relatively easy to obtain a fundamental building block for client-side content 
pristine digital content and to pirate the content at the 50 security is a secure operating system. If a computer can be 
expense and harm of the publisher. booted only into an operating system that itself honors 
Piracy of digital content, especially online digital content, content rights, and allows only compliant applications to 
is not yet a great problem. Most premium content that is access rights-restricted data, then data integrity within the 
available on the Web is of low value, and therefore casual machine can be assured. This stepping-stone to a secure 
and organized pirates do not yet see an attractive business 55 operating system is sometimes called "Secure Boot." If 
stealing and reselling content. Increasingly, though, higher- secure boot cannot be assured, then whatever rights man- 
value content is becoming available. Books and audio agement system the secure OS provides, the computer can 
recordings are available now, and as band widths increase, always be booted into an insecure operating system as a step 
video content will start to appear. With the increase in value to compromise it. 

of online digital content, the attractiveness of organized and 6Q Secure boot of an operating system is usually a multi- 
casual theft increases. stage process. A securely booted computer runs a trusted 
The unusual property of digital content is that the pub- program at startup. The trusted program loads an initial layer 
lisher (or reseller) gives or sells the content to a client, but of the operating system and checks its integrity (by using a 
continues to restrict rights to use the content even after the code signature or by other means) before allowing it to run. 
content is under the sole physical control of the client. For 65 This layer will in turn load and check the succeeding layers, 
instance, a publisher will typically retain copyright to a work This proceeds all the way to loading trusted (signed) device 
so that the client cannot reproduce or publish the work drivers, and finally the trusted applications). 
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An article by B. Lampson, M. Abadi, and M. Burrows, The identity of an operating system running on a com- 

entitled "Authentication in Distributed Systems: Theory and puter is determined from an identity associated with an 

Practice/' ACM Transactions on Computer Systems vlO, initial component for the operating system, combined with 

265, 1992, describes in general terms the requirements for identities of additional components that are loaded after- 

securely booting an operating system. The only hardware 5 wards. Loading of a digital rights management operating 

assist is a register that holds a machine secret. When boot syslcm on a subscriber computer is guaranteed by validating 

begins this register becomes readable, and there's a hard- digital s i gnat ures on each component to be loaded and by 

ware operation to make this secret unreadable. Once it's deterrninin g a trust level for cach component. A trusted 

unreadable, it stays unreadable until the next boot. The boot iden(i fc hdd b the di M d h{s management operating 

code mints a public-key pair and a certificate that the m when Qn ncnts with yalid signaturcs and a 

operating system can use to authenticate itselt to other j * ■ j . * 1 1 ijj • *u 

parties in order to establish trust. We note that in this P [ e - de *™™ d tniSt ^ are ^ oaded \°^T-f 

scheme, a malicious user can easily subvert security by * tm & s ^ ^ associated with an un trusted identity. Both 

replacing the boot code the trusted and untrusted identities are derived from the 

dark and Hoffman's BITS system is designed to support components that were loaded, 

secure boot from a smart card. P. C.Clark and L.J. Hoffman, 15 The initial component is described variously as a boot 

"BITS: A Smartcard Operating System/' Comm. ACM. 37, block, or a set of components required to boot the operating 

66, 1994. In their design, the smart card holds the boot system. 

sector, and PCs are designed to boot from the smart card. i n another aspect of the invention, a record of the loading 

The smart card continues to be involved in the boot process of each component is placed into a boot log. The boot log is 

(for example, the smart card holds the signatures or keys of 20 protected from tampering through a chain of public-private 

other parts of the OS). key paifS ^ 0 f mc boot log are used to determine 

Bennet Yee describes a scheme in which a secure proces- whether the operating system is to be considered trusted or 

sor first gets control of the booting machine. B. Yee, "Using untrusted 

Secure Coprocessors". Ph.D. Thesis, Carnegie Mellon rr ' . , , _ . , . . A ... A . . 
University/1994. The secure processor can check code 25 L1 U f e of / s P e ,? al Public-private key pair to validate a boot 
integrity before loading other systems. One of the nice t block ^ to alleviate .^placement , issues should a standard 
features of this scheme is that there is a tamper-resistant ke V P au be "^Promised is also disclosed, 
device that can later be queried for the details of the running The guaranteed loading of a digital lights management 
operating system. operating system on a general-purpose personal computer 
Another secure boot model, known as AEGIS, is dis- 30 ensures that downloaded content can be protected from 
closed by W, Arbaugh, D. G. Farber, and J. M Smith in a unauthorized access. Furthermore, the generation of an 
paper entitled "A Secure and Reliable Bootstrap identity for an operating system based on its loaded corn- 
Architecture", Univ. of Penn. Dept. of CIS Technical Report, ponents allows a content provider to knowledgeably deter- 
IEEE Symposium on Security and Privacy, page 65, 1997. mkie whelher t0 trust content t0 subscriber computer. 
This AEGIS model requires a tamper-resistant BIOS that has 35 The present invention describes systems, clients, servers, 
hard-wired into it the signature of the following stage. This methods, and computer-readable media of varying scope. In 
scheme has the very considerable advantage that it works addition to the aspects and advantages of the present inven- 
well with current microprocessors and the current PC tion described in this summary, further aspects and advan- 
architecture, but has three drawbacks. First, the set of trusted tages of the invention will become apparent by reference to 
operating systems or trusted publishers must be wired into 40 the drawings and by reading the detailed description that 
the BIOS. Second, if the content is valuable enough (for follows, 
instance, e-cash or Hollywood videos), users will find a way 

of replacing the BIOS with one that permits an insecure BRIEF DESCRIPTION OF THE DRAWINGS 

boot. Third, when obtaining data from a network server, the RG 1A ^ a di of ^ hardware and operating 

client has no way of proving to the remote server that it is 45 environment in conjllnctioil with which exemplary embodi- 

indeed running a trusted system. ments of ^ mvention may be practiced; 

On the more general subject of client-side rights c «. 4 , c 

& , • * u u a * FIG. IB is a diagram of a client computer for use with 

management, several systems exist or have been proposed to 1 . j- . * <u • *• 

6 . ' t , . . . . . ■ . . * exemplary embodiments of the invention; 

encapsulate data and rights in a tamper-resistant software r 3 

package. An early example is IBM's Cryptolope. Another 50 FIG. 2 is a diagram illustrating a system-level overview of 
existent commercial implementation of a rights management an exemplary embodiment of the invention; 
system has been developed by Intertrust. In the audio FIG. 3 is a flowchart of a method to be performed by a 
domain, AT&T Research have proposed their "A2b" audio client when booting or loading system components accord- 
rights management system based on the PolicyMaker rights ing to an exemplary embodiment of the invention; 
management system. 55 FIG. 4 is a diagram of a certificate revocation list data 
Therefore, there is a need in the art for guaranteeing that structure for use in an exemplary implementation of the 
a digital rights management operating system has beeo invention; 

properly loaded on a computer. Furthermore, such a digital pi G 5 a flowchart of a method to be performed by a 

rights management operating system must be readily dis- client to create a boot log according to an exemplary 

cernable from a non-trusted operating system executing on 60 embodiment of the invention; 

the same computer. FIG. 6 is a block diagram of an exemplary boot log 

SUMMARY OF THE INVENTION created using the method of FIG. 5; 

The above-mentioned shortcomings, disadvantages and FIGS. 7 A, 7B and 7C are block diagrams of boot blocks 

problems are addressed by the present invention, which will 65 fc> r use in an exemplary embodiment of the invention; 

be understood by reading and studying the following sped- FIG. 8 is a block diagram of key generation functions 

fication. according to an exemplary embodiment of the invention; 



04/29/2004, EAST Version: 1.4.1 



US 6,327,652 Bl 



FIG. 9 is a diagram of a rights manager certificate data 
structure for use in an exemplary implementation of the 
invention; 

FIG, 10 is a diagram of a required properties access 
control list data structure for use in an exemplary imple- 
mentation of the invention; and 

FIG. 11 is a diagram of a license data structure for use in 
an exemplary implementation of the invention. 

DETAILED DESCRIPTION OF THE 
INVENTION 

In the following detailed description of exemplary 
embodiments of the invention, reference is made to the 
accompanying drawings, which form a part hereof, and in 
which is shown by way of illustration specific exemplary 
embodiments in which the invention may be practiced. 
These embodiments are described in sufficient detail to 
enable those skilled in the art to practice the invention, and 
it is to be understood that other embodiments may be utilized 
and that logical, mechanical, electrical and other changes 
may be made without departing from the spirit or scope of 
the present invention. The following detailed description is, 
therefore, not to be taken in a limiting sense, and the scope 
of the present invention is defined only by the appended 
claims. 

The detailed description is divided into four sections. In 
the first section, the hardware and the operating environment 
in conjunction with which embodiments of the invention 
may be practiced are described. In the second section, a 
system level overview of the invention is presented. The 
third section described methods and data structures 
employed by various exemplary embodiments of the inven- 
tion. Finally, in the fourth section, a conclusion of the 
detailed description is provided. 

Hardware and Operating Environment 

FIG. 1A is a diagram of the hardware and operating 
environment in conjunction with which embodiments of the 
invention may be practiced. The description of FIG. 1A is 
intended to provide a brief, general description of suitable 
computer hardware and a suitable computing environment in 
conjunction with which the invention may be implemented. 
Although not required, the invention is described in the 
general context of computer-executable instructions, such as 
program modules, being executed by a computer, such as a 
personal computer. Generally, program modules include 
routines, programs, objects, components, data structures, 
etc. that perform particular tasks or implement particular 
abstract data types. 

Moreover, those skilled in the art will appreciate that the 
invention may be practiced with other computer system 
configurations, including hand-held devices, multiprocessor 
systems, microprocessor-based or programmable consumer 
electronics, network PCs, minicomputers, mainframe 
computers, and the like. The invention may also be practiced 
in distributed computing environments where tasks are 
performed by remote processing devices that are linked 
through a communications network. In a distributed com- 
puting environment, program modules may be located in 
both local and remote memory storage devices. 

The exemplary hardware and operating environment of 
FIG. 1A for implementing the invention includes a general 
purpose computing device in the form of a computer 20, 
including a processing unit 21, a system memory 22, and a 
system bus 23 that operatively couples various system 



25 



30 



45 



50 



60 



components, including the system memory 22, to the pro- 
cessing unit 21. There may be only one or there may be more 
than one processing unit 21, such that the processor of 
computer 20 comprises a single central-processing unit 
(CPU), or a plurality of processing units, commonly referred 
to as a parallel processing environment. The computer may 
be a conventional computer, a distributed computer, or any 
other type of computer; the invention is not so limited. 

The system bus 23 may be any of several types of bus 
structures including a memory bus or memory controller, a 
peripheral bus, and a local bus using any of a variety of bus 
architectures. The system memory may also be referred to as 
simply the memory, and includes read only memory (ROM) 
24 and random access memory (RAM) 25. A basic input/ 
output system (BIOS) 26, containing the basic routines that 
help to transfer information between elements within the 
computer 20, such as during start-up, is stored in ROM 24. 
The computer 20 further includes a hard disk drive 27 for 
reading from and writing to a hard disk, not shown, a 
magnetic disk drive 28 for reading from or writing to a 
removable magnetic disk 29, and an optical disk drive 30 for 
reading from or writing to a removable optical disk 31 such 
as a CD ROM or other optical media. 

The hard disk drive 27, magnetic disk drive 28, and 
optical disk drive 30 are connected to the system bus 23 by 
a hard disk drive interface 32, a magnetic disk drive inter- 
face 33, and an optical disk drive interface 34, respectively. 
The drives and their associated computer-readable media 
provide nonvolatile storage of computer-readable 
instructions, data structures, program modules and other 
data for the computer 20. It should be appreciated by those 
skilled in the art that any type of computer-readable media 
that can store data that is accessible by a computer, such as 
magnetic cassettes, flash memory cards, digital video disks, 
Bernoulli cartridges, random access memories (RAMs), 
read only memories (ROMs), and the like, may be used in 
the exemplary operating environment. 

A number of program modules may be stored on the hard 
disk, magnetic disk 29, optical disk 31, ROM 24, or RAM 
25, including an operating system 35, one or more applica- 
tion programs 36, other program modules 37, and program 
data 38. A user may enter commands and information into 
the personal computer 20 through input devices such as a 
keyboard 40 and pointing device 42. Other input devices 
(not shown) may include a microphone, joystick, game pad, 
satellite dish, scanner, or the like. These and other input 
devices are often connected to the processing unit 21 
through a serial port interface 46 that is coupled to the 
system bus, but may be connected by other interfaces, such 
as a parallel port, game port, or a universal serial bus (USB). 
A monitor 47 or other type of display device is also 
connected to the system bus 23 via an interface, such as a 
video adapter 48. In addition to the monitor, computers 
typically include other peripheral output devices (not 
shown), such as speakers and printers. 

The computer 20 may operate in a networked environ- 
ment using logical connections to one or more remote 
computers, such as remote computer 49. These logical 
connections are achieved by a communication device 
coupled to or a part of the computer 20; the invention is not 
limited to a particular type of communications device. The 
remote computer 49 may be another computer, a server, a 
router, a network PC, a client, a peer device or other 
common network node, and typically includes many or all of 
the elements described above relative to the computer 20, 
although only a memory storage device 50 has been illus- 
trated in FIG. 1. The logical connections depicted in FIG. 1 
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include a local-area network (LAN) 51 and a wide -area the private key "K^j/ 1 " In this way, only the CPU knows 

network (WAN) 52. Such networking environments are the CPU private key K^p^" 1 ; the same key is not issued to 

commonplace in offices, enterprise-wide computer other CPUs and the manufacturer keeps no record of it. The 

networks, intranets and the Internet. certificate can in principle be stored on a separate physical 

When used in a LAN-networking environment, the com- * device associated with the processor but still logically 

puter 20 is connected to the local network 51 through a belongs to the processor with the corresponding key. 

network interface or adapter 53, which is one type of The manufacturer has a pair of public and private signing 

communications device. When used in a WAN-networking keys, K MFR and K^^" 1 . The private key K^" 1 is known 

environment, the computer 20 typically includes a modem only to the manufacturer, while the public key K^^r is made 

54, a type of communications device, or any other type of 10 available to the public. The manufacturer certificate 166 

communications device for establishing communications contains the manufacturer's public key K MRr , the CPU's 

over the wide area network 52, such as the Internet. The public key K^ Pt/ , and the above testimony. The manufacture 

modem 54, which may be internal or external, is connected signs the certificate using its private signing key, K^^ -1 , as 

to the system bus 23 via the serial port interface 46. In a follows: 

networked environment, program modules depicted relative is Mfr Certificateo(W) certifies-for-Boot, K CPU \ signed by 

to the personal computer 20, or portions thereof, may be iwr 1 

stored in the remote memory storage device. It is appreciated m „ u ._ „ , „ . ,,«_*«_ 

that the nctworkconnections shown arc exemplary and other ™ e P^dica e "certifies-for-boot b a pledge by the manu- 

means of and communications devices for establishing a facturer thlt * created CPU ™ d C ™ ^ Pf* r 

communications link between the computers may be used. «> according to a known speculation The pledge farther states 

. . . that the CPU can correctly perform authenticated boot 

The hardware and operating environment m conjunction procedureSj as are descr ibed below in more detail. The 

with which embodiments of the invention may be practiced mami f acturer certificate 166 is publicly accessible, yet it 

has been described. The computer in conjunction with which cannQt be fo . without knowledge of me manufacturer's 

embodiments of the invention may be practiced may be a private key K^" 1 

conventional computer, a distributed computer, or any other 25 The cpu ^ has m internal software identity register 

type of computer; the invention is not so limited. Such a (gIR) lfig which ^ idendty of an authcnticated 

computer typically includes one or more processing units as ating system 180 or a predetermined false value (e.g., 

its processor, and a computer-readable medium such as a , if ^ cpu determines that the 0 p era ting system 180 

memory. The computer may also include a communications cannQt be authenlicatedt ^ operating system (OS) 180 is 

device such as a network adapter or a modem, so that it is stored ^ ^ memory U2 md executedon thc CPU 140t 

able to communicatively couple to other computers. operating system 180 has a block of code 182 that is used to 

One exemplary embodiment of a suitable client computer authenticate the operating system to the CPU during the boot 

is described in the related application titled "System and operation. The boot block 182 uniquely determines the 

Method for Authenticating an Operating System to a Central 35 ope r a ting system, or class of operating systems (e.g. those 

Processing Unit, Providing the CPU/OS with Secure signed by tne same marm f ac turer). The boot block 182 can 

Storage, and Authenticating the CPU/OS to a Third Party," also be s i gned by the OS manufacturer, 
and illustrated in FIG. IB as subscriber unit 124. The CPU 

140 in the subscriber unit 124 is able to authenticate the System Level Overview 

identity of the boot block and OS components that have been 4Q ^ system level overview of the operation of an exemplary 

loaded into the computer, and to provide quoting and secure embodiment of the invention is described by reference to 

storage operations based on this identity as briefly described pic. 2. A subscriber computer 200, such as client computer 

next. Full descriptions of various embodiments for the 20 in FIG. 1, is connected to a content provider server 

subscriber unit 124 arc provided in the related application. computer 220, such as remote computer 49, through a 

The CPU 140 has a processor 160 and also can have a 45 wide-area network, such as WAN 52. Processes performed 

cryptographic accelerator 162. The CPU 140 is capable of by the components of the subscriber computer 200 and the 

performing cryptographic functions, such as signing, content provider 220 are illustrated by arrows in FIG. 2. 

encrypting, decrypting, and authenticating, with or without Many of these processes incorporate either public/private 

the accelerator 162 assisting in intensive mathematical com- key pairs, digital signatures, digital certificates, and/or 

putations commonly involved in cryptographic functions. 50 encryption algorithms, or a combination of these standard 

The CPU manufacturer equips the CPU 140 with a pair of cryptographic functions. Such functions are assumed to be 

public and private keys 164 that is unique to the CPU. For provided by the CPU of the subscriber computer in the 

discussion purpose, the CPU's public key is referred to as descriptions that follow, but can be provided by other 

"Kcpu" and the corresponding private key is referred to as well-known cryptographic mechanisms as will be immedi- 

"Y^pu 1 ". Other physical implementations may include 55 ately understood by one skilled in the art. 

storing the key on an external device to which the main CPU To prevent their content from being stolen or misused, 

has privileged access (where the stored secrets are inacces- content providers will download content only to known 

sible to arbitrary application or operating systems code). The software, and therefore only to subscriber computers that 

private key is never revealed and is used only for the specific can prove that their operating systems will enforce the 

purpose of signing stylized statements, such as when 60 limitations the provider places on the content. Such a digital 

responding to challenges from a content provider, as is rights management operating system (DRMOS) must load 

discussed below. and execute only OS components that are authenticated as 

The manufacturer also issues a signed certificate 166 respecting digital rights ("trusted"), and must allow access 

testifying that it produced the CPU according to a known to the downloaded content by only similarly trusted appli- 

specification. Generally, the certificate testifies that the 65 cations. 

manufacturer created the key pair 164, placed the key pair The first requirement is met in the exemplary embodiment 

onto the CPU 140, and then destroyed its own knowledge of of the invention by having all trusted operating system-level 
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components digitally signed by their developers or a trusted certificate 210 to determine whether it should establish a 

third-party, with the signature acting as a guarantee that the trust relationship with the DRMOS 205 on the subscriber 

components respect digital rights. The signature is validated computer 200. 

before the component is loaded. The resulting DRMOS is In an alternate exemplary embodiment, the challenge- 
assigned a unique trusted identity, as explained in detail 5 response protocol runs over a secure connection such as SSL 
below, which is recorded in an internal register in the CPU, (Secure Socket Layer) or TLS (Transport Level Security), 
such as SIR 168 in FIG. IB. FIG. 2 illustrates a DRMOS which relies on a session key to encrypt the data transferred 

205, with its identity 206, after it has been loaded into the between the subscriber computer 200 and the content pro- 
CPU 201 of a subscriber computer 200 through such a vider 220. This stops an attacker (such as the legitimate 
loading process 1 10 owner of the machine) from rebooting the PC into a different 

The second requirement has two aspects. First, trusted °P eratiD S ^ tem after lhe DRMOS has authenticated itself, 

applications must be identified in some fashion, and, second, ™ a different computer on the network for snooping on 

the DRMOS must prevent non-trusted applications from the data destined for the DRM0S 

gaining access to the content when it is stored, either If the trust relationship is established, the provider down- 
permanently or temporarily, on the subscriber computer. ^ loads 6 the content 221, an access predicate 222, and a 

j • . ... , u . ™ , \ t A "license" 223 to the DRMOS 205 on the subscriber corn- 
In the exemplary embodiment shown in FIG. 2, a trusted i - nn _ t .„ 
i- *• mnL j j t • j vu *u puter 200. The access predicate 222 specifies the properties 
application 209 has agreed to operate in accordance with the f. A v 4 . \. . \ *u ♦ ♦ 
* a ♦ /u • j jt« . j that an application must have in order to process the content 
limitations placed on content by a provider. The trusted ... \f , - . . , *\ . , 

i- irtft * j * a j a. u «■ u* ^ 221, such as read-only or minimum/maximum video reso- 

apphcation 209 is identified through a "rights manager' ' predicate 222 mav also soecifv specific 

certificate 210. In one embodiment, the rights manager 20 Ml ° n - ™ e acce f P redlcate ^ may also specify specinc 

, . a . i t j j j- v i J?ti * i • . applications or families of applications allowed to process 

certificate 210 extends a standard digital certificate, which ™ 4 4 r 21 a . ♦ ■ »■„ t u 

* i j i_ a * f ur *■ a p *u the content 221. The hcense 223 places restrictions on the 

includes such items as date of publication and name of the c ^ , . , r , . . m . _ 

i . . * , j,. i* . r • ^ ■ use of the content 221 by an approved application, such as 

application, by adding a list of services, or properties, , - ,. J . r * , rr , , , 

^ , / i • * * * u ji j the number of times the content can be accessed or what 

provided by the application, i.e,, content type handled, , . . , A c , . 

version of the application, whether it saves it to disk, ^ # t _ . 

etc. For purposes of the exemplary embodiment shown in When DR ^ 0S 205 receives the content 221, the 

FIG. 2, the certificate 210 also identifies the trusted appli- at f es i s P re u dlcate 222 and ^ he u hcense 223 > 11 ^terimnes 

cation; alternate mechanisms for identifying a trusted appli- ** cther th f content should be permanently stored in a 

cation are described later in the methods section. key-secured storage H so it requests an application storage 

^ ,^ Wrt0 . , , - _ 30 key from the CPU 201. In the present example, the apph- 

The DRMOS 205 provides key-secured storage for per- J [on & k ^ ific {Q {h& appLication 20 9 that 

manently stored content to prevent unauthorized access to ted the corltent 22 1. The content 221 and the license 

the content. For temporarily stored content the DRMOS 205 223 are ted ^ the ap pi ica t io n storage key and the 

prevents an untrusted process from reading the memory acce&s dicate n2 fc aUached to ^ encrypted informa „ 

holding the content These and other safeguards are also 35 {{m }f ^ 2n fe tQ be stored Qnly temporarilVj lhe 

described in detail below. Hie permanent and temporary DRMOS 205 places various safeguards around the memory 

storage within subscriber computer 200 are coUectively area hcM ^ conteQt ^ ^ ^ camot be 

represented by device 203, which is illustrated in FIG. 2 as accessed b aR untrusted appl i cat ion. The generation of 

a disk drive. Such illustration is not intended to limit the y cation storage keys and the memory safeguards are 

range of devices that can serve as secured storage for a 4Q described in detail below , 

DRMOS. g ac ^ t ^ me app ij cauon 209 wants to access the stored 

Turning now to the remainder of the processes depicted in coatent 221? it passes its rights manag er certificate 210 and 

FIG. 2, application 209 requests 2 the download of content ^ appr0 priate application storage key (action 8) to the 

221 from provider 220. The DRMOS 205 sends a message DRMOS 205. The DRMOS 205 validates the key and 

3 to the provider 220 requesting the content 221. The content 45 compares me rights manager certificate 210 against the 

provider 220 transmits a challenge message 4 to the access predicate 2 22. Assuming the storage key is authen- 

DRMOS 205 asking for the identity of the CPU 201, the ticated and the rights manager certificate 210 satisfies the 

DRMOS 205, and the application 209. The DRMOS 205 access predicate 2 22, the content 221 and the license 223 are 

transmits a response message 5 containing a certificate 202 decrypted. The DRMOS determines if the application's use 

for the CPU 201, its own identity 206, and the rights 50 0 f the content is permitted under the license 223 and allows 

manager certificate 210 for the application 209. access 9 if it is. 

The challenge-response process follows the common pro- The S y S t e m level overview of the operation of an exem- 

tocol for such interchanges, the difference being only in the plary embodiment of the invention has been described in this 

data exchanged between the subscriber computer and the section of the detailed description. A series of processes and 

content provider. In one exemplary embodiment of a suit- 55 data structures on a subscriber computer control the loading 

able challenge-response process described in the related of a digital rights management operating system, identify the 

application titled "System and Method for Authenticating an DRMOS and trusted applications to a content provider, and 

Operating System to a Central Processing Unit, Providing secure content downloaded by the provider to the subscriber 

the CPU/OS with Secure Storage, and Authenticating the comput cr. While the invention is not limited to any particu- 

CPU/OS to a Third Party/' the certificate 202 contains the 60 l ar hardware and software, for sake of clarity only a minimal 

challenge message 3, the identity of the DRMOS 206, the hardware and software configuration necessary to process 

public key of the CPU 201, and data representing all multimedia has been assumed for the subscriber computer, 
software components that are currently loaded and executing 

on the subscriber computer 200. The certificate 202 is signed Methods of Exemplary Embodiments of the 

using the private key of the CPU 201. The content provider 65 Invention 

220 examines the CPU certificate 202, the DRMOS identity In the previous section, a system level overview of the 

206, and the properties specified in the rights manager operation of exemplary embodiments of the invention was 
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described. In this section, the particular methods performed untrusted component after the boot process completes, a 

by a subscriber computer, or client, of such exemplary plug-and-play DRMOS must then "renounce" its trusted 

embodiments are described by reference to a series of identity and terminate any executing trusted applications 

flowcharts and operational diagrams. The methods to be (block 323) before loading the component. The determina- 

performed by the client constitute computer programs made 5 tion that an untrusted component must be loaded can be 

up of computer-executable instructions. Describing the based on a system configuration parameter or on instructions 

methods by reference to flowcharts and operational dia- from the user of the computer. 

grams enables one skilled in the art to develop such pro- Assuming the signature is valid (block 305) and the 

grams including such instructions to carry out the methods component is trusted (block 309), it is loaded (block 311). 

on suitable computerized clients (e.g., on the processor of a 10 ^ ^worthiness of a component can be decided using 

client executing the instructions from computer-readable v ™ criteria In one embodiment only components pro- 

media). Data structures necessary to perform the methods v f d b V system developer are trusted At the 

, ' , »i i • .i • T, J. *u j p iu # other end of the scale, in another embodiment, all compo- 

are also described in this section. The methods or the content ' , . . nnwA^ i ■ * <_ 

. . _ , a^~-u~a t~ _i ^ t i nents are assumed trustworthy by the DRMOS, leaving the 

provider server computer are described to complete the _ , , . . , 7 3 . , , ' , . & 

r . c *u *u j _f ju*u r • final decision to the content provider as described in more 

understanding of the methods performed by the client. 15 , „ , , » ,.■ * ^ . 

, r , , , , , detail below. Still a third alternate embodiment provides that 

Although many of the methods are interrelated, they have components signed by any of a xhdL number of entities can 

been divided into four groups to facilitate understanding. be considered ^ equivalent t0 compon ents provided by the 

T^e boot^oad process and various mechanisms for creating DRMOS developer. In this embodiment, the identity of the 

identitiesfordifferentversi^ ^ { m fc ccmsidered equivalent to the 

operating system (DRMOS) are tot described. Hie func- 20 urc „ DRMQS ^ ^ DRMQS devel The 

lions that must be provided by the DRMOS to ensure the idef whemer - t tmsts the equi valent 

enforcement of the content providers rights are described operating system 

next. The third group consists of methods directed toward „ . " n . r . , 

t t c*u ♦ # *u u -u Furthermore, not all versions of a component may be 

providing permanent storage or the content on the subscriber t , _ ' , . Ut *•« . . • *u 

F A &y j , j, , . . , , „ trusted. Because the nghts manager certificate contains the 

computer once downloaded, and protecting that content 25 . , 9 , , A . . c 

- * ,i . j !?• II *u a 4- a *• t version number of the component, it can be used to verify 

from unauthorized access. Finally, the identification of . . . - , ., * . ' n„« «f tkl 

, . ■ J4 . . t 4 * t *• the trust level of a particular version. One embodiment of the 

trusted applications and the rights management functions are , ,. , r . . .. 

j , , -v, j loading process checks a component certification revocation 

described. . . „ rrt0 list (CRL) to determine whether a component signature has 

Booting/Loading and Identifying the DRMOS ^ been reyoked The CRL can be provided by mc content 

Referring first to FIG. 3, a flowchart of a method to be provider or the DRMOS developer. An exemplary embodi- 

performed by a subscriber computer according to an exem- ment 0 f a CRL is illustrated in FIG. 4. Each entry 401 

plary embodiment of the invention is shown. This method is contains the name of the component 403, the version 405, 

inclusive of the acts required to be taken by the computer to and tne signer 407 whose signature is revoked. The particu- 

boot a DRMOS or to load additional components after the ^ j ar CRLused becomes part of the operating system identity 

boot process is complete. Exemplary embodiments of boot using a standard hashing function described further below, 

block data structures are described below in conjunction Alternatively, if the rights manager certificates on the 

with FIGS. 7A-C. components are short-lived and must be renewed 

Shortly after a computer is turned on or is reset, a small periodically, then a version that is found to be untrustworthy 

program called a boot loader is executed by the CPU (block 4Q w in no t have its certificate renewed. This alternate embodi- 

301). The boot loader loads a boot block for a particular me nt requires a secure time source to be available on the 

operating system. Code in the boot block then loads various subscriber computer so the user cannot simply turn back the 

drivers and other software components necessary for the system clock on the subscriber computer. A monotonic 

operating system to function on the computer. The totality of counter in the CPU can serve as this secure time source since 

the boot block and the loaded components make up the 45 ft on iy counts up and cannot be reset "back in time." For 

identity of the operating system. example, a monotonic counter that is periodically incre- 

For a DRMOS, that identity can be trusted only if the boot mented while the CPU is active, and that cannot be reset, can 

block and the loaded components are trusted. In the embodi- be used in conjunction with a secure time service, such as a 

ments described herein, all components are signed by a secure Internet time service, to provide a lower bound on the 

trusted source and provided with a rights manager ccrtifi- 50 current time in a trusted manner. Such exemplary use of a 

cate. An exemplary embodiment of the rights manager monotonic counter is described in detail below as part of the 

certificate is described below in conjunction with FIG. 9. functions of the DRMOS. 

The operating system checks the signature of a compo- Once all components are loaded, the operating system 

nent before loading it (block 303). If the signature is valid assumes its identity (block 315). In one embodiment, a 

(block 305), the component has not been compromised by ss one-way hashing function provided by the CPU is used to 

someone attempting to circumvent the boot process and the create a cryptographic "digest" of all the loaded compo- 

process proceeds to check the level of trust assigned to the nents. The digest becomes the identity for the operating 

component (block 307). If the signature is not valid (or if system and is recorded in an internal register in the CPU, 

there is no signature) but the component must be loaded Alternate methodologies of assigning an identity to the 

(block 319), the operating system will not assume the 60 loaded components are equally applicable as long as a 

identity of a DRMOS upon completion of the boot process non-trusted configuration cannot have the same identity as a 

as explained further below. DRMOS. Signing the operating system identity with a 

A plug-and-play operating system provides an environ- private key particular to the type of CPU serves to identify 

ment in which devices and their supporting software com- both the operating system and the processor on which it is 

po nents can be added to the computer during normal opera- 65 executing. 

tion rather than requiring all components be loaded during If all computers were identically configured, a single, 

the boot process. If the device requires the loading of an signed operating system identity would suffice to authenti- 
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cate a particular operating system executing on a particular 
type of CPU. However, computers contain a myriad different 
hardware components, and the corresponding supporting 
software components are frequently updated to add enhance- 
ments and fix problems, resulting in a virtually unlimited 
number of operating system identities. Therefore, the con- 
tent provider would have to maintain a registry of each 
subscriber's DRMOS identity or delegate that function to a 
trusted third party. 

The problems attendant on having a vast number of 
DRMOS identities can be alleviated in at least three ways. 
First, an identity is generated or assigned for the basic 
configuration of each operating system. Such a basic con- 
figuration includes only components supplied by the oper- 
ating system vendor. The identity is generated (or assigned) 
and stored when the basic components have been loaded. 
Different versions of the basic operating system will gener- 
ate (or be assigned) different identities. 

Once the basic configuration of a DRMOS is loaded and 
its trusted identity is stored, subsequent components 
required to support the particular hardware configuration 
must be verified and loaded as explained in conjunction with 
FIG. 3. Such additional software components can also 
include updates to the basic components provided by ven- 
dors other than the operating system developer. Each addi- 
tional loaded component has an individual identity (such as 
a cryptographic digest) generated/assigned and stored. All 
the identities are uploaded to the content provider when the 
DRMOS identity is requested. Because the basic DRMOS 
and additional components always have the same identities 
when executing on a specific type of processor, the content 
provider has only to maintain a list of the identities for the 
combinations of the basic DRMOS and additional compo- 
nents that the provider trusts. Each identity uploaded is then 
checked against the list. 

In a second alternate embodiment, the operating system 
maintains a "boot log," containing the identity of the basic 
DRMOS and the identities of the additional OS components 
that have been loaded. The identity is a cryptographic digest 
of the code for the component, or a well-known name, or any 
other sting that is uniquely associated with the component. 
The CPU also maintains a composite identity register that 
holds a one-way cryptographic function of the boot log. 
Whenever a component is loaded, its identity is appended to 
the boot log and folded into the composite identity register, 
such as by setting this register to a secure hash of its old 
value appended with the new component's identity. When- 
ever the CPU certifies the current value of its composite 
identity register, it also verifies that the operating system's 
boot log has not been tampered with. Because the log is 
indelible, the loaded component cannot erase the record that 
shows it was loaded. 

An alternate exemplary embodiment of the boot log holds 
the entire boot log in the CPU. The DRMOS uses an 
instruction provided by the CPU that appends the identity of 
each loaded component to the log. The CPU then signs the 
boot log to attest to its validity and delivers the signed boot 
log to the content provider as the identity for the DRMOS. 

In another alternate embodiment, DRMOS uses a chain of 
public and private key pairs newly generated by the CPU to 
create an indelible boot log. The method is shown in FIG. 5 
and an exemplary embodiment of the completed boot log is 
illustrated in FIG. 6. The boot loader generates or obtains a 
first key pair (Kq, Kq -1 ) and records the first key pair in 
memory (block 501). The first public key is also saved to 
secure storage in the CPU. The boot loader loads the boot 



block into memory and records the identity of the boot block 
in the boot log (block 503). Before turning control over to 
the boot block code, the boot loader obtains a second key 
pair (K a , K^ -1 ) (block 505), writes the second public key 

5 (K a ) to the boot log (block 507), and then signs the boot log 
with the first private key (Kq -1 ) (block 509). The boot loader 
deletes the first private key (Kq" 1 ) from its memory (block 
511) and relinquishes control to the boot block. 
The boot block code loads additional components into 

10 memory, records the identities of those components to the 
boot log (block 515), obtains a third key pair (K^ K^ 1 ) 
(block 505), appends the boot log with the third public key 
(KJ (block 507), and signs its portion of the boot log with 
the second private key K^ 1 (block 509). The boot block 

1S erases the second private key (Kj -1 ) (block 511) from 
memory and turns control of the boot process over to the first 
loaded component. Each loaded component that will load 
additional components obtains a new key pair (K„, K^" 1 ) 
and uses the private key of the previous key pair (K n _ 1 ~ 1 ) to 

20 sign its portion of the boot log. The boot process continues 
in this iterative manner through until all components arc 
loaded or, in the case of a plug-and-and play DRMOS, a 
content provider challenge is received (block 513). 
When a non-pfug-and-play DRMOS resumes control after 

2 5 the final component is loaded, it places a "sentinel" on the 
boot log (block 519) to indicate that the log is complete and 
to prevent a loaded component from deleting entire lines of 
the log. The characteristics of the sentinel are that is a 
known, unique value that is signed using the last private key 

3 q (K„ -1 ). In the present embodiment, the sentinel is a signed 
zero entry. The DRMOS deletes the last private key and all 
public keys from memory after creating the sentinel. 

Because a plug-and-play DRMOS cannot arbitrarily 
declare that all components arc loaded at the end of the boot 

35 process, the DRMOS cannot add a sentinel to the end of the 
boot log at that time. Instead, the DRMOS attests to its most 
recent public key K„ as well as its first public key Kq to 
certify the contents of the boot log when challenged. 
Using a chain of key pairs 606, 607, as shown in FIG. 6, 

40 guarantees the boot log reflects the loaded components. 
Each public key in a log section is used to authenticate the 
signature on the next section. The first public key remains in 
memory to authenticate the signature on the boot block 
section of the log. While each set of components is free to 

45 load more components, a component cannot change the 
recording of its identity in a previous portion of the log 
because doing so would cause the validity check on the 
corresponding signature to fail. Similarly, a section in the 
middle of the log cannot be deleted because that would break 

50 the chain of keys. Deleting multiple sections of the log 
through to the end also breaks the chain. In this case, 
attempting to insert a new sentinel in an effort to make the 
log appear unaltered will fail because the private key nec- 
essary to add the sentinel is no longer available. Finally, the 

55 entire boot log cannot be replaced since the signature on the 
boot block section of the log would not be validated by the 
first public key. 

Turning now to the boot block, one exemplary embodi- 
ment suitable for use with a digital rights management 

60 operating system is shown in FIG, 7 A. The boot code 701 is 
signed (signature 703) by the developer of the DRMOS 
using its private key. The corresponding public key 705 of 
the developer is attached to the boot block 700. In an 
alternate embodiment, the public key 705 is not attached to 

65 the boot block 700, but instead is persistently stored in an 
internal register in the CPU. The public key 705 is used to 
validate the signature 703. 
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If the DRMOS developer's private key used to sign the An example of one kind of procedure that must be 

boot block is compromised, the key pair must be changed prohibited is loading a kernel debugger because it would 

and thus all boot blocks must be reissued to subscriber allow the user to make a copy of the content loaded in 

computers. FIG. 7B illustrates an alternate embodiment of a memory. If the user of the subscriber computer attempts to 

boot block that ameliorates this problem. Boot block 710 5 load a kernel debugger into memory, the DRMOS can either 

comprises a basic boot section 711 and an intermediate boot 1) refuse to load the debugger, or 2renounce its trusted 

section 713. The basic boot section 711 contains boot code identity and terminate the trusted application that was 

715 that validates and loads the intermediate boot section accessing the content before loading the debugger. In the 

713 and components not provided by the DRMOS devel- latter case, the memory must also be purged of the content 

oper. The intermediate boot section 713 contains boot code before the debugger is loaded. The choice of action can be 

717 that validates and loads components from the DRMOS pre-determined or chosen by the user when the user attempts 

developer. The intermediate boot section 713 is signed with to load the kernel debugger. One of skill in the art will 

a special boot block private key. The basic boot code 715 immediately identify other types of programs that will need 

uses a corresponding boot block public key 719 stored in the to be treated in the same manner as a kernel debugger, 

basic boot section 711 to validate the intermediate boot Virtual memory operating systems maintain a page file 

section 713. Components 727 from the DRMOS developer that holds sections of program code and data that are not 

are signed 729 with the developer's standard private key and currently active. Under normal circumstances, the contents 

the intermediate boot section 713 uses the DRMOS devel- of the page file are accessible by the user of the computer, 

oper's standard public key 721 to validate those compo- either by running a privileged program or by booting another 

nents. operating system that allows inspection of the disk. 

If the standard private key used to sign components is Therefore, a DRMOS must either protect content stored on 

compromised, the developer creates a new standard key pair the page file or must not page content and similar protected 

and provides a replacement intermediate boot block 713 information at all. 

containing the new standard public key. Replacement com- Protecting content on the page file can be accomplished in 

ponents signed with the new standard private key are also 25 at least three ways. First, the DRMOS can prohibit all "raw" 

issued. Because the special boot block private key is used for access to page file device when a trusted application is 

few, if any, other purposes than signing boot blocks, it is less running. Second, the DRMOS can terminate all trusted 

likely to be compromised and replacement of the basic boot applications and erase the page file before allowing such 

section 711 will rarely be necessary. access. Third, the DRMOS can encrypt the content and 

In FIG. 7C, an alternate embodiment of the single section 30 similar protected information before writing it to the page 

boot block 730 also uses a special boot block key pair. The file. 

boot block 730 contains the special boot block, or master, Often, a DRMOS must allow the user to perform certain 

public key 733. The master private key is used to certify standard functions but prohibit other, related functions. The 

ephemeral keys that are valid for a short period of time. DRMOS can assign the user permissions based on the 

Certificates signed 737 by the master private key attest to the 35 granularity of the normally permitted function. For example, 

validity of the ephemeral keys. A component is signed with the DRMOS can allow the user to delete an entire content 

one of the ephemeral private keys and the corresponding file but not a portion of it. Another example is that the 

certificate 739 is attached. The boot block determines that DRMOS can allow the user to terminate all the threads of 

the certificate on the component is valid using the master execution for a trusted application but not just a single 

public key. When the ephemeral key expires, the DRMOS 40 thread. 

developer issues replacement components. As with the two- Finally, a DRMOS must protect the trusted application 

section boot block shown in FIG. 7B, the master private key itself from tampering. The DRMOS must not allow other 

is only used to sign the certificates for the ephemeral keys so processes to attach to the process executing the trusted 

it is less likely to be compromised. Because the ephemeral application. When the trusted application is loaded into 

keys are valid for only a short duration, public release of a 45 memory, the DRMOS must prevent any other process from 

private ephemeral key has limited impact. reading from, or writing to, the sections of memory allocated 

Functions of a DRMOS to the trusted application without the explicit permission or 

As described above, components may be valid only until cooperation of the trusted application, 

a specified date and time, and content may also be licensed Key-based Secure Storage 

only until a certain date and time. The mono tonic counter 50 In order to protect content permanently stored on the 

described earlier can also be used to ensure that the com- subscriber computer, the DRMOS must provide a secure 

puter's clock cannot be set backwards to allow the replace- storage space. In essence, the DRMOS must securely store 

ment of a trusted component by an earlier, now untrusted private keys or session keys for use with encrypted content, 

version. The DRMOS connects on a regular basis to a trusted or provide some other mechanism for keeping these keys 

time server and presents the value of its monotonic counter, 55 secret from other OSs or system level software. These keys 

whereupon the trusted time server returns a certificate bind- can be used for the secure storage and retrieval of protected 

ing that value to the current time. If the monotonic counter information. In the exemplary embodiments described in 

is updated periodically, such as every hour that the DRMOS this section, the information to be stored in a protected 

is ruling, then the monotonic counter in conjunction with the format is encrypted using one of a set of keys that may be 

most recent time certificate can serve as a useful approxi- 60 generated by a function 800 (FIG. 8) provided by the CPU. 

mation to a trusted clock. The storage key generation process is tightly coupled to the 

A DRMOS must also protect the content once it is loaded DRMOS so that the same key cannot be generated by the 

into the client computer's memory by a trusted application. CPU for an unrelated operating system, or by any software 

In particular, the DRMOS must prohibit the use of certain on another computer. Three types of storage keys are envi- 

types of programs and refrain from performing certain 65 sioned as illustrated in FIG. 8: an OS storage key 801, an 

common operating system procedures when content is in application storage key 811, and a user storage key 821. 

memory. Each key is specific to the entity that requests it. 
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Beginning with the OS storage key 801, the DRMOS 
passes a "seed" 803 as an operand of a key -gene rati on 
instruction ("Generate Key") 805 to the CPU and receives an 
OS storage key based on the seed 803 and the identity of the 
DRMOS. The CPU will always return the same OS storage 
key 801 when the same seed 803 is provided by the same 
DRMOS but will return a different OS storage key if the 
same seed 803 is provided by an unrelated operating system. 
Because an unrelated operating system cannot get the same 
key 801, it cannot read any data encrypted by the DRMOS. 

In an alternate embodiment, only a single operating 
system storage key is used by the DRMOS as described 
below. Therefore, in this embodiment only the identity of the 
DRMOS is factored into the key generation function 800 
and the seed 803 is not necessary. 

An application storage key 811 is generated when an 
application calls an operating system instruction 
("GenerateApplKey") 815 using a seed 813. The DRMOS 
passes the seed 813 through an application-specific one-way 
hash function 817 to produce a hashed seed 819. The hashed 
seed 819 is then passed to the CPU through the GenerateKey 
instruction described above. The resulting application stor- 
age key 811 is returned to the application for use. Because 
the GenerateKey function uses the operating system's 
identity, the same application executing under an unrelated 
operating system cannot get the same key, and therefore 
cannot access the encrypted data, even if it requests the key 
using the same seed 813. Similarly, an unrelated application 
using the same seed 813 gets a different key because the 
DRMOS passes the seed 813 through a different hash 
algorithm for each application. 

In an alternate embodiment, the operating system stores 
decryption keys for applications using its own identity; the 
applications call the operating system to retrieve application 
keys. This also provides a way for an application to allow 
other applications access to its key and therefore to the 
content encrypted by the key. Instead of creating a secret 
using a seed 813, the application passes in the access 
predicate for the content. The access predicate designates 
values that must be present in the rights manager certificate 
for an application wishing access to the content. An exem- 
plary embodiment for an access predicate is shown in FIG. 
9 and described in detail in the following section. The 
DRMOS supplies the seed 813 that is required to generate 
the application specific key and passes the seed 813 through 
a generic one-way hash. The DRMOS encrypts the seed 813 
and the access predicate using an OS storage key and 
associates the encrypted access predicate with the encrypted 
seed. When any application requests access to a key pro- 
tected by an access predicate, the DRMOS compares the 
criteria ill the access predicate against the rights manager 
certificate of the requesting application. An application that 
meets the criteria is given access to the seed 813 and 
therefore to the application storage key. Because the seed 
813 is encrypted using an OS storage key, an application that 
is running under an unrelated operating system will be 
unable to gain access to the encrypted data because the 
unrelated operating system cannot decrypt the seed 813. 

Finally, a particular user can request a key that is based on 
a user identity assigned by the DRMOS or another facility 
that guarantees a unique identity for each user. The user 
supplies a seed 823 in a "GenerateUserKey" call 825. The 
operating system passes the seed 823 through a one-way 
hash 828, and then passes the resulting first hashed seed 827 
through a keyed hash routine 829 to generate a second 
hashed seed 833. The operating system factors the user 
identity 831 into the keyed hash routine 829 so that the 
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second hashed seed 833 is unique to the user. The second 
hashed seed 833 is passed to the CPU, which returns the user 
storage key 821. As described above, only the same user will 
be able to access data encrypted with the storage key 821 
when the DRMOS that generated the key is executing. 
Analogously, the keyed hash routine 829 guarantees that the 
user storage key will not duplicate either an OS storage key 
or an application storage key based on the same seed, Such 
a facility is used when downloaded content can be accessed 
only by a particular user. Moreover, if downloaded content 
is to be accessed only by a particular user and by a particular 
application, the secret to be stored may be divided into parts, 
with one part protected by an application -specific key and 
the other part protected by a user-specific key. 

Once the data is encrypted using the storage keys, there 
must be a way to recover the keys when the DRMOS 
identity changes (as when the operating system is upgraded 
to an incompatible version or an unrelated operating system 
is installed) or the computer hardware fails. In the exemplary 
embodiments described here, the keys are stored off-site in 
a "key vault" provided by a trusted third party. In one 
embodiment, the DRMOS contains the IP addresses of the 
key vault providers and the user decides which to use. In 
another embodiment, the content provider designates a 
specific key vault and the DRMOS enforces the designation. 
In either embodiment, when the user requests the restoration 
of the storage keys, the key vault provider must perform a 
certain amount of validation before performing the down- 
load. The validation process can include such actions as 
recording the identity of the original operating system (or 
computer) in a revocation list, checking the frequency of the 
requests, and requiring a credit card number before down- 
loading the storage keys. 

Rights Management 

Most operating systems do not directly process media 
content, such as video or audio. That function is usually 
available through special application programs. Therefore, a 
content provider must not only trust the operating system but 
must also trust the application that will process the content. 
Content also can be accompanied by a predicate stating 
which applications are to be trusted to access that content, 
and this statement can include a list of generic properties that 
implicitly define a set of applications. Further associating a 
rights manager certificate with the application provides 
identification of the application and certification of its prop- 
erties. This allows the content provider to determine if the 
application fulfills the requirements of the content provider 
before downloading content, and also allows the operating 
system to restrict future access to only the appropriate 
applications. 

One exemplary embodiment of a rights manager certifi- 
cation is shown in FIG. 9. A list of application properties 903 
is appended to the digital certificate fields 901 standard in 
some digital certificate format such as X.509. The certificate 
names the application. Each entry 905 in the list 903 defines 
a property 906 of the application, along with optional 
arguments 907. For example, one property might be that the 
application cannot be used to copy content. Another 
example of a property is one that specifies that the applica- 
tion can be used to copy content, but only in analog form at 
480P resolution. Yet another example of a property is one 
that specifies that the application can be used to copy 
content, but only if explicitly allowed by an accompanying 
license. Additional examples include the right to store an 
encrypted copy of the content and to restrict such storage to 
only certain, acceptable peripheral devices. The property 
906 can also be used to specify acceptable helper 
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applications, such as third-party multimedia processing 
stacks or other libraries, to be used in conjunction with the 
application named in the certificate. The certificate is signed 
by an operating system vendor, content provider, or third 
party, certifying the properties of the application. 

Because the content provider must trust the DRMOS and 
application to protect the content from misuse once 
downloaded, the content provider attaches an access predi- 
cate to the content. This access predicate can also include a 
license to the content. The basic functions of both the access 
predicate and the license, which were described in the 
system overview, are explained in detail next. 

In one embodiment, the access predicate takes the form of 
a required properties access control list (ACL) as shown in 
FIG. 10. The required properties ACL 1000 contains a basic 
trust level field 1001, which specifies the minimum rights 
management functions that must be provided by any appli- 
cation wishing to process the content. These minimum 
functions can be established by a trade association, such as 
the MPAA (Motion Picture Association of America), or by 
the DRMOS vendor. A unique identifier is used to reference 
a list of the minimum functions. The minimum functions list 
can include CPU, DRMOS, and application specific require- 
ments. 

The required properties ACL 1000 can also contain one or 
more extended trust level fields 1003. The extended trust 
level fields 1003 contains identifiers that specify additional 
rights management function that must be provided by the 
subscriber computer. For example, a required properties 
ACL can require that only a certain version of a particular 
application be allowed access to the content. The required 
properties ACL 1000 is compared against the certificates for 
the CPU, the DRMOS, and the application starting at the 
hardware level, i.e., CPU, DRMOS, application name, 
version, and specific properties for the application. One of 
skill in the art will readily recognize that the required 
properties ACL 1000 can require that all properties must be 
present, or at cast one of the properties, or some specified 
subset. 

The content license (FIG. 11) imposes additional restric- 
tions on what kind of processing can be performed on the 
content once an application has access to the content. As 
described briefly above, the license data structure 1100 can 
limit the number of times the content can be accessed (usage 
counter 1101), determine what use can be made of the 
content (derivation rights 1103), such as extracting still shots 
from a video, or building an endless loop recording from an 
audio file, or a time-based expiration counter 1105. 

The license can also specify whether or not a trusted 
application is permitted to validate other client computers 
and share the content with them (sublicense rights 1107), in 
effect having the subscriber computer act as a secondary 
content provider. The sublicense rights 1107 can impose 
more restrictive rights on re -distributed content than those 
specified in a license for content downloaded directly from 
the original content provider. For example, the license 1100 
on a song purchased directly from the music publisher can 
permit a song to be freely re-played while the sublicense 
rights 1107 require a limit on the number of times the same 
song can be re-played when re -distributed. To enforce the 
sublicense rights 1107, in one embodiment, the trusted 
application modifies the original license 1100 to specify the 
additional restrictions and downloads the modified license 
with the re-distributed content. In an alternate embodiment, 
the original content provider downloads a sublicense along 
with the content and that sublicense is re-distributed by the 
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trusted application when it redistributes the content. The 
sublicense is structurally identical to the license data struc- 
ture 1100 although the content of the fields differs. 
Additional licensing restrictions will be readily apparent 

5 to one skilled in the art and are contemplated as within the 
scope of the invention. 

The license 1100 is stored with the content on secured 
storage. In one embodiment, the required properties ACL 
1000 is also stored with the license 1100 and the content. In 

10 an alternate embodiment, the ACL 1000 is secured sepa- 
rately and controls access to the storage key for the content 
as described above. 

In the embodiments described above, the DRMOS is 
responsible for checking the required properties ACL and for 

15 enforcing the licensing restrictions. By providing the vali- 
dation functions in the DRMOS, the functions are central- 
ized and can be utilized by any process. In an alternate 
embodiment, the validation functions concerning the appli- 
cation are coded directly into the trusted applications pro- 

20 grams. A similar effect is achieved in yet another alternate 
embodiment that places the application validation functions 
in a library that is incorporated into the trusted applications. 
One of skill in the art will immediately perceive that 

2S certain rights are more easily enforced at the DRMOS level, 
such as the right for a certain application to access a key or 
other content, or the ability to open a file a limited number 
of times, while other types of rights are best enforced by the 
application itself. Since the DRMOS enforces the restriction 

30 that only explicitly stated applications can access restricted 
content, the application can be trusted to enforce the addi- 
tional restrictions. Alternate embodiments in which the 
enforcement of certain rights is allocated to the DRMOS and 
the enforcement of others to the application is therefore 

35 contemplated as within the scope of the invention. 

As described above in conjunction with FIG. 2, the 
content provider 220 delivers content to the subscriber 
computer 200 after trust is established by transmitting the 
appropriate certificates/identities for the CPU, the DRMOS, 

40 and the application to the provider. The content can be 
explicitly encrypted by the content provider for this combi- 
nation of CPU, DRMOS, and application, as described 
above, or, if the content is sent over a secured link (with, for 
example, Secure Socket Layer services), the content pro- 

45 vider can encrypt the content using the session key for the 
secure link. In the latter embodiment, the DRMOS writes the 
encrypted content to permanent storage and uses one of the 
storage keys generated by the CPU to securely store the 
session key for later use. Alternately, the content provider 

50 can choose not to encrypt the content if it is transmitted to 
the application in a secure fashion, in which case the 
application performs the encryption if it stores a persistent 
copy of the content. 

The particular methods performed by a subscriber com- 

55 puter of an exemplary embodiment of the invention have 
been described. The methods performed by the subscriber 
computer have been shown by reference to flowcharts, 
operational diagrams, and data structures. Methods per- 
formed by the content provider have also been described. 

60 

Conclusion 

A digital rights management system has been described 
whereby certain cryptographic secrets are reliably associ- 
ated with a particular digital rights management operating 
65 system or family of operating systems running on a particu- 
lar general-purpose computer. The operating system uses 
these secrets to authenticate itself to a third party, to receive 
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encrypted content or information, to store this content or 
information securely, and to retrieve it later. No unrelated 
operating system or other software running on the same 
computer can obtain these secrets and perform these actions, 
nor can any operating system or other software running on 
any other computer. By using these cryptographic secrets, 
the digital rights management operating system can recur- 
sively provide derived cryptographic secrets for the same 
uses by applications running on the same operating system 
on the same computer. 

Although specific embodiments have been illustrated and 
described herein, it will be appreciated by those of ordinary 
skill in the art that any arrangement that is calculated to 
achieve the same purpose may be substituted for the specific 
embodiments shown, This application is intended to cover 
any adaptations or variations of the present invention. 

For example, those of ordinary skill in the art will 
appreciate that various combination of the exemplary 
embodiments are applicable to solve the digital rights man- 
agement problem depending on the exact computing envi- 
ronment. Furthermore, those of ordinary skill in the art will 
recognize that the invention can be practiced on a large scale 
although illustrated herein with only a single subscriber and 
content provider. 

The terminology used in this application with respect to is 
meant to include all hardware and software configuration 
and all networked environments. Therefore, it is manifestly 
intended that this invention be limited only by the following 
claims and equivalents thereof. 

We claim: 

1. A computerized method for loading components in an 
operating system comprising: 

verifying a source for each component before the com- 
ponent is loaded; 

establishing a trust level for each component before the 
component is loaded; 

loading each component if the source of the component is 
trusted and the trust level of the component satisfies 
trust criteria; and 

generating a trusted identity for the operating system 
when specific components have been loaded. 

2. The computerized method of claim 1, further compris- 
ing: 

loading a component if the source of the component is 
untrusted; and 

generating a non-trusted identity for the operating system. 

3. The computerized method of claim 1, further compris- 
ing: 

loading a component if the trust level for the component 

does not satisfy the trust criteria; and 
generating a non-trusted identity for the operating system. 

4. The computerized method of claim 1, further compris- 
ing: 

loading a component if the trust level for the component 

does not satisfy the trust criteria; and 
generating an identity unrelated to the trusted identity for 

the operating system. 

5. The computerized method of claim 1, wherein the trust 
criteria are based on a digital signature associated with the 
component. 

6. The computerized method of claim 1, wherein the trust 
criteria are based on a list of trusted components. 

7. The computerized method of claim 6, wherein the list 
of trusted components comprises a plurality of digests for 
trusted components. 
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8. The computerized method of claim 1, wherein the trust 
criteria are based on the source of the component. 

9. The computerized method of claim 1, wherein the trust 
level is different for different versions of a component. 

5 10. The computerized method of claim 9, wherein the 
trust criteria is satisfied if the version of the component to be 
loaded is not signed by a revoked digital signature listed in 
a certification revocation list. 

11. The computerized method of claim 1, wherein the 
1Q trusted identity is generated from the loaded components 

using a one-way hash function. 

12. The computerized method of claim 1, wherein the 
specific components comprise base components. 

13. The computerized method of claim 1, further com- 
prising: 

35 generating a trusted identity for each component loaded 
after the trusted identity for the operating system has 
been generated. 

14. The computerized method of claim 1, further com- 
prising; 

20 recording the loading of the components in a boot log. 

15. The computerized method of claim 14, wherein the 
boot log is maintained by a central processing unit, wherein 
the central processing unit is operable for certifying a 
current value for the boot log. 

25 16. The computerized method of claim 14, wherein a 
secure hash of the boot log is maintained by central pro- 
cessing unit, wherein the central processing unit is operable 
for certifying a current value for the boot log. 

17. The computerized method of claim 14, wherein 
30 recording the loading of the components in the boot log 

comprises: 

obtaining a first private key and a corresponding first 
public key; 

storing the first public key in a secure location; and 
35 for each one of a plurality of component subsets, per- 
forming a signing loop until all component subsets 
have been signed, the signing loop comprising: 

recording the loading of the component subset in the boot 

log; 

40 obtaining a new private key and a corresponding new 
public key; 

recording the new public key in the boot log; 
digitally signing the boot log with the immediately prior 
private key; and 
45 deleting the immediately prior private key. 

18. The computerized method of claim 14, further com- 
prising: 

recording a sentinel to the boot log, wherein the sentinel 
is a pre-determined value signed with the new private 
50 key; and 

deleting the new private key. 

19. The computerized method of claim 14, further com- 
prising: 

attesting to the new public key and the first public key to 
55 authenticate the operating system. 

20. The computerized method of claim 1, wherein one of 
the components is a boot block. 

21. The computerized method of claim 1, wherein the 
elements are performed in the order recited, 

60 22. A computer-readable medium having stored thereon a 
boot block data structure comprising: 

a certificate entry containing data representing a certifi- 
cate that identifies a digital rights management system; 
a boot code entry containing data representing computer- 
65 executable instructions for booting the digital rights 
management system identified by the certificate entry; 
and 
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a boot block signature entry containing data representing 
a source that provided the computer-executable instruc- 
tions in the boot code entry, wherein the data in the boot 
block signature entry is verified using the data in the 
certificate entry. 

23. The computer-readable medium of claim 22, further 
comprising: 

a boot block public key entry containing data representing 
a special public key for the source; 

an intermediate boot code entry containing data repre- 
senting additional computer-executable instructions for 
booting the digital rights management system identified 
by the certificate entry; 

a special signature entry containing data representing the 
source that provided the computer-executable instruc- 
tions in the boot code entry, wherein the data in the 
special signature entry is verified using the data in the 
boot block public key entry; and, a standard public key 
entry containing data representing a standard public 
key for the source. 

24. A computer system comprising: 
a processing unit; 

a system memory coupled to the processing unit through 
a system bus; 

a computer-readable medium coupled to the processing 
unit through a system bus; and 

an operating system boot block executed from the 
computer-readable medium by the processing unit, 
wherein the boot block causes the processing unit to 
validate subsequent components to be loaded by the 
boot block, and to generate an identity for the operating 
system based on the loaded components. 
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25. The computer system of claim 24, wherein the boot 
block causes the processing unit to validate a subsequent 
component by checking a signature on the component. 

26. The computer system of claim 25, wherein the boot 
block causes the processing unit to validate a subsequent 
component by further determining a trust level for the 
component. 

27. The computer system of claim 24, wherein the boot 
block causes the processing unit to load only subsequent 
components that are validated. 

28. The computer system of claim 24, wherein the boot 
block causes the processing unit to generate an identity that 
is trusted when only validated components are loaded. 

29. The computer system of claim 26, further comprising: 
a loaded component executing block executed from the 

computer-readable medium by the processing unit, 
wherein the loaded component causes the processing 
unit to validate subsequent components to be loaded by 
the loaded component. 

30. The computer system of claim 24, further comprising: 
a boot log facility executed from the computer-readable 

medium by the processing unit, wherein the boot log 
facility causes the processing unit to record an identity 
for each component loaded in a boot log. 

31. The computer system of claim 24, wherein the boot 
log facility further causes the processing unit to generate a 
plurality of public and private key pairs, to record each 
public key in a separate portion of the boot log and to sign 
each portion of the boot log with a private key. 
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